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INTEGRATED METHOD OF INTERNATIONAL TRADE 

This application is a continuation in part of US patent application Serial 

No. , entitled "International Trade System," filed October 1, 2001, under 

applicants' docket no 10012318-1, which is incorporated herein by reference for all 
5 purposes. 

The present invention relates generally to international trade, and more 
particularly, to integrated systems, software and related business methods for handling 
international trade in a multitude of trade scenarios. 

BACKGROUND OF THE INVENTION 

10 International business transactions frequently lead to issues in the 

international transportation of goods. The transactions can take place between related 
or unrelated business entities, any of whom could be barred from international trade 
by certain countries or with their citizens and corporations. The goods can be finished 
products for the consumer market or components for use in manufacture. They 

15 likewise can be environmentally sensitive or toxic goods, goods restricted for security 
reasons, and/or goods packaged in ways that must be reported in certain countries. The 
goods can be subject to export license requirements, import duties, and customs 
regulations. These issues can arise with each international border crossed by the 
goods, even goods that are simply in transit through a jurisdiction. 

20 A typical commercial shipment could involve nine different participants, 

20 separate documents, 35 customer-vendor interactions and four modes of transport. 
It could require weeks or months to complete, and can cross several international 
borders. Thus, an elaborate supply chain including manufacturers, distributors, 
retailers and transportation service providers including freight forwarders, carriers and 

25 customs brokers has developed around the world. The resulting global transportation 
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industry is one of the largest and most complex in the world, requiring a high level of 
expertise in a variety of transportation issues that vary from legal jurisdiction to 
jurisdiction. 

In this complex marketplace of services, buyers and sellers are frequently 
inexperienced, lacking knowledge of the wide variety of legal requirements placed on 
international transportation by each country. As a result, a large corporation with 
thousands of buyers and sellers world wide can have extreme variation in its practices. 
This potentially leads to noncompliance or inconsistent compliance with various 
national laws, excessive delivery times, additional expenses in customs, shipping and 
brokering, and unclaimed drawbacks from refundable duties. Furthermore, because 
transportation procedures are not consistently maintained, little quality control can be 
exercised in monitoring preferred procedures and selecting better-performing service 
providers. A noncompliance with national laws is particularly important, as it can lead 
to both extreme financial penalties and the arrest and incarceration of people ignorantly 
conducting transactions violating the law. 

Additionally, costs and delivery time are highly variable, and 
predictability is limited by a lack of consistent procedures and historic information. 
Thus, purchasers often must make purchasing decisions without a realistic 
understanding of the total cost and/or time to delivery. 

Presently, interaction between importers, exporters and their service 
providers is primarily conducted via paper, phone and facsimile. The industry lacks 
industry-based universal formats and standards, and customers use different sets of 
processes with each service provider. Information from global logistics typically 
remains disconnected from enterprise systems designed to drive efficiencies across 
global supply chains. 
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In attempting to automate and standardize processes, numerous 
transportation service providers have developed automated processes within their areas 
of expertise. Such efforts have produced tax services, shipment tracking services, 
customs invoicing services, duty calculation services, customs classification services, 
5 import regulation services, export regulation services, and a large host of other 
applications. For a customer to take advantage of each such application, that customer 
(e.g., buyer, seller or related service provider) must know to use the application, 
purchase access to the application, learn to use the application, and provide all relevant 
information for the application to use. Additionally, because these solutions can be 
[ |0 regional in applicability, and because these solutions can be inferior for some types of 
transactions or locations, while superior for others, their consistent use by a user 
familiar with just the one application can be limited in effectiveness by its inferiority 
when used for other jurisdictions . 

M= In some cases, providers are bundling these point solutions into packages 

•15 of related software. For example, there are bundles of software configured for tax 
calculation, bundles of software for landed cost calculation, bundles of software 
^ configured for export issues and bundles of software configured for import issues. 

These bundles combine specific point solutions, and therefore adopt their 
limitations and weaknesses. They each commonly operate without consideration of 

20 factors from numerous other substantive or jurisdictional areas. For example, packages 
for estimating costs cannot typically consider the incremental costs incurred in export 
(e.g., license requirements and restricted party limitations), import (e.g., duties and 
environmental limitations), logistics (e.g., shipping costs thatvary based on a particular 
customer's pricing agreements), taxes (e.g., customer preferences for claiming "assists" 

25 and other tax related activities) and other such issues. Furthermore, even presuming 
that all customers could be trained and educated on the use of each such bundle, 
separate business arrangements and technology connections need to be established and 
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maintained for each bundle, adding to the overall cost of conducting international 
transportation of goods. 

Additionally, accessing individual bundles does not provide the 
integrated information to accurately predict total transaction cost and delivery time. 
5 Thus, purchasers and/or sellers continue to take risks on cost and delivery time, or they 
avoid the purchase of goods in international trade. 

Accordingly, there has existed a need for an improved system for 
O international trade and the conduct of international business transactions. Such a 

system would preferably provide for improved speed, accuracy, legality and 
: 30 consistency. Preferred embodiments of the present invention satisfy these and other 

needs, and provide further related advantages. 

SUMMARY OF THE INVENTION 

; In various embodiments, the present invention solves some or all of the 

needs mentioned above, providing systems, software and related business methods for 
1 5 handling the international transportation of goods. 

The in certain embodiments, the inventive method relates to includes a 
method of conducting an international transaction in goods between a buyer and a 
seller. The buyer has an intended destination for the goods, and the seller has location 
that the goods either exist or will be manufactured. The invention includes a server 

20 that identifies a source country for the seller's goods and a buying country for the 
buyer's destination for the goods. Based on this information, the server queries a 
shipping module to calculate a total shipping cost for shipping the goods along a 
shipping rout to the service level. It also queries a brokering module to calculate a total 
brokering cost for brokering the goods along the shipping rout, and a tax module to 

25 calculate a total tax cost for the sale and transportation of the goods. 
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The invention features the server providing a total cost to the buyer, the 
total cost including a sale price, the total shipping cost, the total brokering cost and the 
total tax cost. The buyer provides the server with an authorization to conduct the 
transaction, preferably in response to the total cost. The server then transmits shipping 
5 instructions to a carrier, preferably based on the calculated shipping costs, and 
transmits customs invoice information to a customs broker. 

Advantageously, using these features the buyer can make purchasing 
decisions based upon promptly provided actual cost information rather than historic 
data. Furthermore, buyers worldwide can take advantage of this feature, without 
1 0 investing in expensive training for every buyer or outsourcing the purchasing activities 
to an uninterested purchasing service. Furthermore, it provides for consistent and 
predictable transactions that safely meet various legal requirements on a consistent 
basis. 

The invention further features the receiving and tracking status updates 
1 5 regarding the status of the goods in transport to the buyer. Using this information, the 
server can provide status reports in response to status requests received regarding the 
status of the goods. Typically these status requests will come form the relevant parties. 
Advantageously, the frequent updates provided during the importation of goods 
provides both for better planning and early detection of delays, which can be very 
20 advantageous for the buyer. Such tracking is substantially more difficult when a buyer 
either tries to manage all service provider contacts itself, or when a buyer disconnects 
from the purchase process by using a purchasing service . Additionally, the information 
supports the accurate analysis of service provider performance data, thus allowing the 
buyer to purchase services from the service providers that offer the most consistent and 
25 high-quality level of service. 

The invention also features the querying of transaction-restriction 
modules to identify any national restrictions that would make the transaction illegal. 
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These queries, which are preferably done more than once, and which are done at any 
time legally required, assure that the transaction will not be completed if any national 
restrictions making the transaction illegal are identified. 

The invention, in many embodiments, is also a system configured to 
operate with both a plurality of internal service engines that operate within the 
protection of a software firewall, and a plurality of external service engines that operate 
outside the firewall. The internal and external service engines are configured to 
provide a variety of separate services that are not fully integrated. The invention 
features an application server module, being configured to selectively send data to, 
receive data from, and/or share data between the service engines. The application 
server module uses this data passing and sharing to selectively operate the service 
engines and integrate their separate services into an integrated service. Any number 
of users having needed of the integrated service can request the integrated service by 
accessing the application server module via an interface module. 

This feature advantageously provides for efficiently meeting users service 
needs with reduced costs and better results. In particular, by offering the service as an 
integrated service, the system can avoid significant training of each user, both in 
learning all requirements to fulfill the service needs, and in learning how to separately 
operate each service engine. Integration also provides for both a seamless single point 
of entry, a consistent user interface and intelligently guided operation. Furthermore, 
by integrating the applications, there is a significant savings in user time, as the human 
portion of the task is reduced in scope. Additionally, by having an intelligent interface 
that requires all users to deal with every aspect of the service needs, more consistent 
performance is achieved throughout a large company of users, and in cases where legal 
requirements exist, an improved level of legal compliance by the corporation as a 
whole can be achieved. 
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By integrating operations that have a bearing on each other, the features 
of the invention also advantageously provide for better record-keeping, and therefore 
superior accountability is achieved. This leads to lower relationship costs and more 
accurate reporting and compliance with laws and objectives. The centralized 
5 interconnection of the service engines also provides for efficient maintenance and 
simple oversight. Furthermore, modernization and upgrades can be accomplished with 
minimum effort by swapping service engines, leading to better negotiating power with 
outside providers of service engines. 

The invention further features a service engine communication layer 
10 connecting the application server to each service engine. The service engine 
communication layer is configured to translate communication protocols to facilitate 
1 communication between the application server module and service engines that use any 
of a variety of communication protocols. This feature provides for the use of service 
Z engines from a variety of sources without having to purchase reprogramrning services 
15 from the sources. Furthermore, because the service engine communication layer will 
typically have an extensive selection of communication protocols, many new service 
engines can be integrated without any significant investment of time or effort, giving 
a plug-and-play capability to service engines that are not designed to have it. 

Embodiments of the invention can also feature a router configured to 
20 place the service engine communication layer in communication with each external 
service engine via a single hole in the firewall. This feature advantageously allows for 
improved security, while also minimizing necessary programming efforts to integrate 
new service engines. 

A combined message broker is also featured in the invention. The 
25 combined message broker includes an internal within the firewall and an external 
message broker outside the firewall. The internal and external message brokers are 
linked in communication with each other through the firewall. For each interacting 
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service engines, which is a service engines configured to interact with other interacting 
service engines, the combined message broker is configured to provide a 
communications link between the interacting service engines, and with internal and 
external reference servers. In particular, the internal and external message brokers are 
5 configured to communicate with the internal and external components (i.e., service 
engines and reference servers), respectively. Preferably, the combined message broker 
is configured to translate communication protocols to facilitate the interaction between 
the interacting service engines that use different communication protocols. 

Advantageously, these features provide for data communication 
10 capabilities to interlink the service engines, just as the service engine communication 

layer provides interactive communication capabilities to interlink the service engines. 

Thus, these features also aid in providing the advantages of the application server and 

communication layer, such as reduced costs in training, operations, efficiency, 
I. maintenance, and modernization. They also provide performance improvements, end- 
15 to-end transaction visibility, and enable compliance with rules and laws, thereby 

reducing noncompliance issues. 

Other features and advantages of the invention will become apparent 
from the following detailed description of the preferred embodiments, taken with the 
accompanying drawings, which illustrate, by way of example, the principles of the 
20 invention. The detailed description of particular preferred embodiments, as set out 
below to enable one to build and use an embodiment of the invention, are not intended 
to limit the enumerated claims, but rather, they are intended to serve as particular 
examples of the claimed invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 FIG. 1 A is the first part of a vertical, cross-functional flow chart of a process for 

conducting an international sale embodying the invention. 
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FIG. IB is the second part of the vertical, cross-functional flow chart depicted 
in FIG. 1A. 

FIG. 2 is a block diagram of a TLCL system architecture embodying the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The invention summarized above and defined by the enumerated claims 
may be better understood by referring to the following detailed description, which 
should be read with the accompanying drawings. This detailed description of particular 
preferred embodiments of the invention, set out below to enable one to build and use 
particular implementations of the invention, is not intended to limit the enumerated 
claims, but rather, it is intended to provide particular examples of them. 

METHOD OF THE INVENTION 
Online Purchase of Existing Product 

Typical embodiments of the present invention reside in a processes of 
conducting a transaction, including related processes of managing supply chains, 
manufacturing goods, transporting goods, managing legal issues of international 
transportation of goods, conducting financial interactions in the support of transactions, 
and combinations of such processes. The invention can be embodied in a process for 
a buyer to accesses a shopping-type web server over a distributed network and 
purchase goods present in one or more warehouses in countries other than the buyer's 
intended destination for the goods, such as could occur in a consumer transaction. The 
invention can also be embodied in a process for a buyer to accesses e-commerce 
software and order goods to be manufactured in various countries from parts sourced 
in other countries, and delivered to any country desired. 
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With reference to FIGS. 1 A and IB, a buyer 1 1 uses a browser to access 
a commerce-based Web server 13 ("commerce server") over a distributed network such 
as the Internet The buyer might initially transmit or otherwise provide identification 
information to the commerce server, including information about the form of payment 

5 and the intended destination. Alternatively, the buyer might shop and anonymously. 
The commerce server provides the buyer with access to a database of product 
information displayed in an online catalog format. The buyer proceeds through 
catalog-type interactions 15, selecting items of interest and placing them in a virtual 
shopping cart 17. When the buyer is satisfied with the selected purchases, the buyer 

10 proceeds to request a check-out procedure 19. 

If the commerce server 13 has not yet been provided with shipping- 
destination information, it requests that information from the buyer 1 1 . The commerce 
server then queries 2 1 an inventory-tracking module, including a database, to determine 
if the buyer' s selected products are available in the buyer' s selected destination country 

15 or countries. If all or some of the selected products are available in the selected 
destination country, a domestic purchase procedure 23 is conducted for those products. 
The domestic purchase procedure can involve the use of a purchasing system that is not 
configured for international trade. Alternatively, the domestic purchase procedure can 
be managed and conducted using the international-trade capable system described 

20 below, skipping the unnecessary procedural steps such as legal checks and arranging 
brokers. 

If some or all of the products are not available in the selected destination 
country, then the buyer 1 1 is provided the option of investigating the possibility of 
purchasing the products from foreign sources. If the buyer chooses to investigate 
25 foreign sources for the products, then the commerce server identifies the locations of 
one or more potential foreign sources for the products by querying inventory 
management modules, including one or more databases, as appropriate for the various 
countries. For each located foreign source, the commerce server notes the relevant 
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country and a warehouse, and generates a message containing data for a hypothetical 
transaction event 24. Each hypothetical transaction message is transmitted to an 
international-trade server 25 configured to manage issues relating to business tax, 
license (export admMstration), customs and/or logistics (TLCL). 

5 For each hypothetical transaction message, an application server of the 

international-trade server 25 generates a series of messages 27 querying various 
modules such as service engines and/or databases. The application server gathers and 
combines the responses to the queries, fonning an information package describing the 
costs and times required for various shipping and brokering options from the country 

1 0 upon which the hypothetical transaction message was based. 

Some query-messages generated by the application server query service 
engines configured for determining transaction-based restrictions. Based on the 
citizenship of the seller, the citizenship of the buyer, the exporting country, the 
importing country, and any intermediary countries that the goods might travel through, 
15 the service engines examine national-law restrictions on buyers and their related 
parties, sellers, source countries and destination countries. These restrictions could be 
based on criminal history, international relations, and other subjects of national 
concern. The service engines selected by the application server might vary depending 
upon the relevant countries or regions of interest. 

20 Similarly, service engines are queried regarding national limitations based 

on issues such as technology export control, toxic substance control, endangered 
species protection, and the like. In addition to using the above relevant-party and 
country information, these service engines will typically need to query other service 
engines to determine product classification in each country of relevance. 

25 The application server will also generate messages querying databases 

containing information on the various parties' licenses for conducting the hypothetical 
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transaction. In particular, selling parties will be examined to assure that they possess 
all necessary export licenses. 

Based upon transportation requirements, and upon the customs laws of 
the countries involved, the various service-activity providers such as forwarders, 

5 carriers and/or brokers will typically be needed to conduct the export/import operation. 
The application server also queries service engines to determine the best combinations 
of service-activity providers and service levels to provide the most cost-effective and/or 
fast delivery of the products to the buyer. With an established set of one or more 
combinations of service-activity providers and service levels, service-related costs are 

10 established. Preferably the modules establishing the service levels and costs are 
directly linked with systems of the service-activity providers, or are using databases 
updated by the service-activity providers on a regular basis. 

The application server also generates messages querying databases 
containing information on relevant taxes, including sales tax, value-added tax, duties, 
1 5 and the like. 

For each hypothetical transaction message 24, replies to all of the 
application server queries are gathered and compiled in the international-trade server 
25. Using this information, the international-trade server develops a set of one or more 
international trade scenarios regarding cost, shipping and availability data 29, each 
20 scenario being based on a different service level and/or shipping option. The 
international-trade server then responds to the hypothetical transaction message with 
this compiled set of information. 

Preferably, when the commerce server 13 has received a response to 
every hypothetical transaction message, it examines 3 1 whether transaction limitations 
25 restrict me transaction from occurring. If the transaction fans this restriction test for 
all hypothetical transaction events, i.e., th e transaction is restricted from occurring from 
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any foreign source country, then the buyer is notified that an international transaction 
is not available 33. However, if the transaction passes the restriction test for one or 
more hypothetical transaction events, i.e., one or more countries from which the 
transaction could occur were identified, then the various international transaction 
options are summarized and provided to the buyer 35. 

The buyer 1 1 is then given the option to order 37 the goods via any of the 
provided international transaction options. If the buyer elects not to purchase the 
products via any of the provided international transaction options, then the buyer 
returns 39 to web pages supporting catalog interactions 15 on the commerce server 13. 

If the buyer 1 1 elects to purchase the products via an international 
transaction option, then the commerce server 13 concludes the interactive portion of 
the purchase with the buyer, allowing the buyer to proceed back to the catalog or onto 
other activities. The commerce server then generates a message containing data 
relating to an actual transaction, being the transaction selected by the buyer. The actual 
transaction message 41 is transmitted to the international-trade server 25, which 
undertakes management of the various issues that must be addressed to complete the 
transaction. 

The application server of the international-trade server 25 preferably re- 
verifies all restriction information by again generating query-messages to service 
engines configured for determining transaction-based restrictions. It also preferably 
re-verifies possession of required licenses. If the relevant national laws require it, the 
international-trade server transmits messages to relevant legal compliance modules 
configured to track legal compliance information for subsequent reporting to relevant 
national governments. For example, various data such as packaging information, 
environmental information, and the like, are recorded and stored, for later reporting on 
either a transaction-by-transaction or a periodic summary basis to meet packaging and 
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environmental laws. A wide variety of other such legal reporting requirements might 
be relevant, depending on the laws of the relevant countries. 

Using modules appropriate for the buyer, seller, source country and 
destination country, the international-trade server 25 sends an advance shipping notice 
43 to all relevant parties that require or desire such notice. In particular, notice is 
preferably sent to the buyer 1 1 and the commerce server 13, as well as to a warehouse 
45 containing the goods in the selected source country, and to brokers, forwarders and 
shippers 47, as were previously identified for the selected transaction. These notices 
can be in a variety of electronic formats, and could even include using facsimile or 
postal mail services. Preferably these notices include any total calculated prices and/or 
pricing indications necessary to verify the price levels previously calculated for the 
transaction. 

The commerce server 13 either uses appropriate modules to bill the 
buyer, or waits for proof of delivery to occur before the buyer is billed 49. The buyer 
awaits shipment of the goods 51. In response to the advance shipping notice 43, the 
warehouse, the brokers, and all notified freight forwarders and carriers undertake 
preparations 53 for their respective service activities. 

Using appropriate modules, the international-trade server 25 transmits a 
message to the warehouse 45 to "pick and pack" 55 the purchased goods for shipment 
to the buyer. The warehouse then packages the goods as necessary, and labels them 
appropriately 57. The warehouse also notifies the international-trade server of the 
anticipated shipment date. The laws of the relevant countries, including the countries 
of citizenship for the buyer and seller, might require that additional checks be made for 
restricted transaction parties such as if the shipment date occurs more than a maximum 
allowable period after the previous restricted party check was made. If an additional 
restricted party check is required, the international-trade server queries the appropriate 
service engines 59, and then sends the appropriate shipment authorization and 
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instructions 6 1 or transaction cancellation to the warehouse, the various service-activity 
providers, and/or the commerce server. The warehouse, forwarders, and/or carriers 
begin transportation of the goods 63. 

The international-trade server also uses appropriate module to generate 
5 customs instructions, including a customs invoice, and transmits these customs 
instructions 65 to the appropriate brokering party or parties. Typically this brokering 
party will be a customs broker, as discussed above. However, in some cases, actual 
parties to the transaction will act as their own customs broker, as may be required by 
national law. Both situations can occur for a single transaction, as the goods might 
10 cross a number of international borders. The brokering party or parties broker the 
goods 64 when they reach appropriate customs stations. 

Throughout the process of packaging, transporting, and brokering the 
goods, status updates are generated 71 and transmitted to the international-trade server. 
: Preferably, status updates are periodically generated by the warehouse, and each 
15 forwarder, carrier and broker involved in the transaction. In particular, each of the 
service providers notifies the international-trade server when they initially take charge 
of the goods, when they deliver and/or otherwise complete their services, and at any 
relevant checkpoints during their services. 

Using appropriate modules, the international-trade server 25 compiles all 
20 status updates in a database. Upon receiving a request 73 from the buyer, from the 
commerce server, or from any other relevant party having access rights to the 
information, the international-trade server generates a report 75 summarizing or 
describing this status of the shipping and brokering activities. 

The final status update is a proof of delivery 81. Upon receipt of the 
25 proof of delivery the international-trade server 25 notifies the commerce server 1 3 that 
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the buyer has received the goods, and that the commerce server is now cleared 83 to 
charge the buyer 85 for the goods if it has not previously done so. 

The various service activity providers will preferably transmit invoices 
to the international-trade server based upon their fees and advanced costs. These 
invoices can be generated on a transaction-by-transaction basis, or on a periodic bases. 
International-trade server modules preferably verify that a status update has been 
received indicating that the service activity provider completed their services. If the 
status update has been received, then international-trade server modules arrange a 
payment to the activity service provider. Individual payments can be made for each 
transaction, or payments can be summed and paid on a periodic basis. At the same 
time, status reports can be reviewed against performance targets, and a database of 
performance data can be updated, providing for the selection of preferred service 
providers in the future. Finally, international-trade server modules preferably bill, and 
receive payment from the commerce server (or its operator) either on a transaction-by- 
transaction basis or periodically. 

Throughout the process, the international-trade server and its various 
modules, e.g., service engines and databases, keep transaction histories to provide an 
accurate accounting of the transaction. These records are used to provide a variety of 
audit reports and conduct other functions. 

Using appropriate modules, the international-trade server 25 conducts 
certain periodic processes to meet government regulations for its buying and/or selling 
entities. In particular, it compiles export information for each selling entity and 
provides it either to that selling entity, or directly to the relevant government. 
Likewise, any governmental reporting of environmental, packaging or other such issues 
is provided. In cases where the goods were originally shipped into the country that 
they were subsequently exported from, and when the international-trade server was 
either involved in that importing operation or was later notified of it, then the 
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international-trade server compiles the information and assists the appropriate entity 
in applying for duty drawbacks, either in actual refunds or duty credits. It also provides 
transaction summaries and reports to meet any national compliance regulations and/or 
audits that the parties might be required to undertake. 

5 Online Purchase of Manufactured-On-Demand Product 

The invention is also embodied in a process for purchasing products 
manufactured at the request of a buyer. The architecture of a system to implement this 
process can be similar to one designed to provide for the process described above. It 
can even use many of the same application servers and modules, i.e., service engines 
10 and databases. 

In mis process, the customer participates in an e-commerce purchasing 
activity, using a web-server environment, a dedicated client-server environment or a 
non-interactive e-commerce software (e.g., inventory replenishment software). The 
buyer could be quoted a fixed price based on previous experience, or a price could be 
15 calculated using methods related to those described above. 

Prior to a price being calculated, a procurement application server sends 
messages to suppliers, who respond with their bid of cost and time to provide parts for 
the goods to be manufactured. Likewise, messages are sent to contract manufactures, 
who respond with their bid of cost and time to provide manufacturing services. 
20 Additionally, the TLCL service engines of an international-trade server, as described 
above, are used to calculate the cost and time figures for the various scenarios of 
transporting goods (both parts and/or final products) so as to provide for the 
manufacture and delivery of the ordered final products. 

All these costs are aggregated, providing an accurate total cost and 
25 delivery time for the buyer to purchase the goods. As in the first described 
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embodiment, the buyer (or its software) then chooses from among the manufacturing 
and transportation options and orders the goods. While payment could be delayed until 
the buyer receives the goods, preferably the buyer arranges payment upon ordering the 
goods, as they are being manufactured at the buyer's instruction. 

5 In a manner similar to the procedure described above, the system notifies 

all part and service providers that their bids have been accepted. The system authorizes 
and manages manufacturing and delivery through a series of instructions and status 
checks. 

In the case where a fixed price was quoted upon order, the price being 
10 based on past experience and/or previous contractual commitments, the bidding for 
parts and manufacture is conducted after the order is placed. The seller then selects the 
part suppliers and manufacturers based on the total cost of the final products, including 
all costs associated with the international trade issues that occur during manufacture 
and delivery. 

15 In cases where the buying entity provides parts across country borders 

to the selling entity for the manufacture of the goods, various options are available to 
the buyer to properly pay the duties on the re-import of the provided parts. This is 
called an "assist" When the international-trade server actually conducts the 
transactions, it tracks the parts, and uses the information (under the buyer's preferred 

20 "assist" accounting methods) in generating customs documents for the importation of 
the goods into the buyer's destination country. 

TLCL SYSTEM ARCHITECTURE 

Typical embodiments of the present invention also reside in a network 
architecture, in computer systems (such as an inter national -trade server), and in related 
25 software, configured for handling international trade. A preferred embodiment of the 
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invention is configured for handling business tax, license (export administration), 
customs and/or logistics (TLCL) issues in the import/export of goods across 
international borders. This preferred embodiment of the invention resides in a system 
to link and direct certain electronic communication between buyers, sellers, customs 
5 brokers, shippers, other service providers, with information and services from various 
computer software service engines, which can be operated and maintained by a variety 
of entities, that are not designed to be integrated with each other. Additionally, 
preferred embodiments of the invention reside in the computer system and related 
software and business methods recited above, when combined with the service engines 
10 to form a networked system for guiding a user through the TLCL issues raised by a 
business transaction spanning one or more international borders. 

Typically, embodiments of this invention integrate a full range of TLCL 
applications, providing distinct business functions, into a single seamless set of 
services. This integration provides synergies that are not typically available to 
15 inexperienced customers. Because the technology includes intelligence in the front 
~ end, users can operate the software without having expertise in TLCL issues. This 
allows a corporation to operate import/export operations legally, efficiently, cost- 
effectively, and consistently, while allowing individual business people to conduct their 
own transactions (i.e., without surrendering complete control to a centralized 
20 department disconnected from the needs and business practices of the individual 
customers). 

CUSTOMERS 

With reference to FIG. 2, the TLCL system is configured to assist and 
guide both buyers and sellers, which will jointly be referred to as Customers 101, 
25 through the range of TLCL issues that they face in cross-border transactions. To be a 
user of the TLCL system, the Customers will typically access a local computer having 
a browser 103. That Customer and their computer are placed in interactive 
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communication with the TLCL system, preferably through a user interface such as a 
web portal 105, via a data communications network such as the Internet 107. These 
communications channels (denoted as interactive by an "I" in FIG. 2) are used for 
interactive communication between a customer and the TLCL system. 

Customers 101 also might possess other computers placed in 
communication with the TLCL system. In particular, Customers may have local 
information systems 109 that communicate with the TLCL system, either via a 
communications network such as the Internet using various standard communications 
protocols, or via direct communication lines established with the TLCL system. These 
communications channels (denoted as being for data transfer by a "D" in FIG. 2) are 
used for low level, computer to computer data transfer that does not involve a Customer 
interactively participating in the transfer. These interactions can be request-an d-reply- 
type communications or data objects (i.e., messages communicating events). The 
customer-based information systems might conduct many different functions relating 
to ordering, accounting, and various TLCL issues. Preferably the customer-based 
information systems will directly communicate with a computer system serving as an 
external message broker 1 1 1 for the TLCL system. 

Large corporate clients of the TLCL system can contain many individual 
TLCL-system Customers 101 spread across many countries. For example, within an 
international conglomerate, there can be many thousands of purchasers and sellers that 
operate separately and distinctly from each other, each having their own information 
systems 109 and their own purchasing and selling procedures. 

In addition to the above facilities, Customers 101 will likely have 
facsimile machines and other communications devices that provide for information 
sharing. Because there is a myriad of possible Customers, there will be a wide variety 
of different communication capabilities among the Customers, even within the same 
corporate client of the TLCL system. Some Customers might not have information 
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systems configured to interact with the TLCL system, some might not have browsers, 
and some might have little to work with other than a telephone. 

Customers 101 will have varying levels of knowledge about the myriad 
of TLCL requirements that international transactions must meet. Some Customers will 
5 have significant experience with transactions across many regions of the world, and 
will be at least somewhat familiar with many countries' TLCL requirements. Other 
Customers will have experience within a certain region, such as the countries of the 
European Union, but will have little knowledge of the TLCL requirements of countries 
outside their region of expertise. Finally, some Customers will have little to no 
10 experience with TLCL issues at all. 

SERVICE ACTIVITY PROVIDERS 

The import/export industry includes a large number of providers of 
service activities to assist buyers and/or sellers in conducting international trade. These 
providers, which shall be referred to as Service Activity Providers 113, include customs 

1 5 brokers, forwarders, carriers, and free-trade zone managers. For example, in countries 
where it is legal, customs brokers typically act as the buyer's agent (or possibly the 
seller' s agent) with the local customs service. Carriers physically transport the goods, 
via plane, track, train, boat or otherwise, and forwarders coordinate carriers for 
complex shipping needs. Free-trade zone managers operate free-trade zones in 

20 countries such as the United States, where they are legal. 

Like the Customers 101 , the Service Activity Providers 1 13 will interact 
with the TLCL system as users, preferably using interactive and data communications 
means (denoted by an "F" and "D", respectively, in FIG. 2). For an interactive 
communication means, the Service Activity Providers can use a local computer having 
25 a browser 115. That computer is placed in interactive communication with the TLCL 
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system, preferably through the web portal 105, via a data communications network 
such as the Internet 107. 

For a data communication means, Service Activity Providers 113 are 
likely to use computers that assist in conducting their business activities, such as for 
generating documents, tracking shipments, scheduling activities, and the like. These 
computers are placed in communication with the TLCL system to communicate 
relevant data. In particular, Service Activity Providers may have local information 
systems 1 17 that communicate with the TLCL system via a means of communicating 
data, such as direct communication lines established with the TLCL system or a 
communications network like the Internet. Preferably the local information systems 
will communicate with the external message broker 1 1 1 for the TLCL system. 

Similar to the Customers 101, the Service Activity Providers 113 will 
likely have facsimile machines and other non-interactive communications devices that 
provide for information sharing. Because there are a large number of Service Activity 
Providers, there are a wide variety of different communication capabilities among the 
Service Activity Providers. Some might not have information systems 117 configured 
to interact with the TLCL system, some might not have browsers 1 15, and in some 
portions of the world, some might be very isolated (e.g., a local transportation company 
in a remote third world location might be very limited in communication facilities). 

Service Activity Providers 113 will often be expert in their field and/or 
their local market. However, they will not often be well acquainted with the 
Customers' goods and the legal concerns raised by those goods. 

TLCL SYSTEM 

The TLCL system is generally under the control and/or direction of a 
TLCL System Provider that owns and operates the TLCL system. The TLCL System 
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Provider can be an entity that requires the TLCL services for its own purposes, such 
as an international conglomerate that has large numbers of buyers and/or sellers 
conducting international business transactions. Alternatively, the TLCL System 
Provider can be an entity who's primary business is the provision of services to 
5 companies that requires the TLCL services. Of course the TLCL System Provider 
potentially can fill both of the above-mentioned roles. Preferably, the TLCL System 
Provider can access the TLCL system both via access to the TLCL system computers, 
and indirectly via a browser in the same manner as a Customer 10 1 or Service Activity 
Provider 113, 

10 Typical embodiments of the TLCL system will include a network of 

computer hardware and software, characterized by an architecture defining a firewall 
123, the web portal 105, and an application management system including an 
application server 125, which could also be referred to as a process server, and a 
service engine communication layer 127. A variety of TLCL services are integrated 

15 and provided through the use of a plurality of service engines. Included among these 
are one or more internal service engines that are within the firewall, and one or more 
external service engines outside the firewall. Some data used by the service engines, 
such as government regulations, classifications and restricted parties, are kept up-to- 
date via data communications with information sources 129. 

20 Strictly interactive internal service engines 13 1 are configured for only 

interactive, real-time processing of TLCL issues for Customers 10 1 or Service Activity 
Providers 1 13, while mixed interactive internal service engines 133 are configured for 
both interactive processing and data-type processing in response to the receipt of 
requests and/or data objects representing various relevant queries and/or events. 

25 Likewise, strictly interactive external service engines 135 are configured for only 
interactive, real-time processing of TLCL issues for Customers 101 or Service Activity 
Providers 1 13, while mixed interactive external service engines 137 are configured for 
both interactive processing and data-type processing in response to the receipt of 
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requests and/or data objects representing various relevant queries and/or events. 
Internal or external devices that only conduct data-type processing in response to the 
receipt of requests representing various relevant queries are referred to as internal 
reference servers 139 and external reference servers 141, respectively. However, while 
5 these devices typically serve in a database capacity, they might conduct some 
processing to meet the requirements of some queries. 

Interactive Processing Communications 

Each service engine configured for interactive processing is in interactive 
communication with the service engine communication layer 127 of the application 
10 management system via an interactive connection (denoted as interactive by an "I" in 
FIG. 2). The service engine communication layer provides translation facilities for 
communication with the wide variety of communication protocols that might be used 
by the service engines. 

In particular, each internal service engine 131 and 133 is linked to the 
1 5 service engine communication layer 127 via an internal interactive connection (denoted 
as interactive by an "F in FIG. 2) configured for communicating interactive 
information. Each external service engine 135 and 137 is preferably linked to a router 
15 1 via an external interactive connection (denoted as interactive by an "I" in FIG. 2) 
configured for communicating interactive information. The router has an interactive 
20 communications link (denoted as interactive by an T' in FIG. 2) placing it in 
communication with the service engine communication layer. The router preferably 
spans the firewall 123, providing for a single "hole" in the firewall to support all 
interactive communications between the service engine communication layer and all 
or most of the external service engines. Optionally, some external service engines 
25 could be in communication with the service engine communication layer through 
separate holes in the firewall that are not maintained by the service engine 
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communication layer and the router. The service engine communication layer can be 
considered a layer of the application server rather than a separate module. 

Within the application management system, the service engine 
communication layer 127 is linked in communication with the application server 125, 
which directs, buffers and processes the various communications between the users and 
the service engines 131, 133, 135 and 137. The application management system 
communicates with the users via the web portal 105. 

The firewall, 123, the web portal 105 and the application server 125 each 
provide authentication and security tasks for verification of the users' interactive usage 
rights in the TLCL system. In particular, the firewall includes a web agent that limits 
web portal access to verified users, thus serving as a gatekeeper to the web portal. The 
web portal 105 also includes a web agent that limits the general types of tasks that each 
user is allowed to conduct Finally, the application server, which governs the operation 
of the service engines, limits access to the particular sub-functions and information for 
which the user has approved access. 

For example, when a customs broker accesses the TLCL system using its 
browser 1 1 5, the firewall web agent verifies that the customs broker is within the group 
of approved users, and then allows the customs broker access to the web portal. At the 
web portal, the customs broker is provided a set of TLCL operations to which the 
customs broker has access. The extent of that set of options is governed by the web 
agent of the web portal 105. After the customs broker selects a function, such as 
customs invoice generation, the application server 125 leads the customs broker 
through a series of interactions with a series of service engines. The application server 
web agent controls the customs broker's access to the individual functions within each 
service engine, based on the customs broker's approved access. The application server 
web agent further controls the customs broker's access, limiting it to data that the 
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customs broker is allowed to access. Thus, security and authentication over interactive 
communications are conducted in three levels. 

Data-Type Communications 

Each service engine configured for data-type processing is interconnected 
5 via connections configured for communicating requests and replies (e.g., database 
queries and related processing), and/or data objects. These data connections are 
denoted as being for data transfer by a "D" in FIG. 2. Depending on the type of data 
transfer, data-type communications are conducted either via a gate-keeping message 
broker or the service engine communication layer 127. 

10 The gate-keeping message broker includes an internal message broker 

161 and the external message broker 111. These two portions of the gate-keeping 
message broker are linked via a data-type communications link 163 passing through a 
hole in the firewall 123. The internal message broker is in data-type communication 
with both the internal reference servers 139 and the internal service engines 133 

1 5 configured for data processing in response to the receipt of requests and/or data objects 
representing various relevant queries and/or events. Likewise, the external message 
broker 1 1 1 is in data-type communication with both the external reference servers 14 1 
and the external service engines 137 configured for data processing in response to the 
receipt of requests and/or data objects representing various relevant queries and/or 

20 events. Through the gate-keeping message broker, these entities can be kept in data- 
type communicati ons . Optionally, some external service engines could be in 
communication with the internal message broker or with internal service engines 
through separate holes in the firewall that are not managed by the router. 

To direct particular queries to which a service engine requires a reply, 
25 such a query is sent by the requesting service engine to the portion of the gate-keeping 
message broker on the same side of the firewall as the requesting service engine. The 


10011098-1 

27 

gate-keeping message broker then directs the query to the appropriate, replying service 
engine or reference server to reply to the request. If the replying service engine or 
reference server is on the opposite side of the firewall from the requesting service 
engine, then the request is appropriately passed between the internal and external 
5 broker portions of the gate-keeping message broker. Similarly, when the reply is 
generated by the replying service engine or reference server, it is sent to the portion of 
the gate-keeping message broker on the same side of the firewall as the replying service 
engine or reference server, and then directed to the requesting service engine, passing 
through the firewall via the gate-keeping message broker if necessary. 

10 An event (i.e., a data object representing relevant activity) can be 

generated in several ways. First, a TLCL system user can interactively initiate an event 
by entering the data via the web portal. Second, a TLCL system user can use a local 
information system 109 or 1 17 to generate an event that is then passed to the external 
message broker 111. Finally, a service engine that is operating on an existing event can 

15 generate data that serves as the basis for further events. 

In each of these cases, the event data are either generated in, or 
communicated to, the application server 125. Events passed to the external message 
broker are communicated through the firewall to the internal message broker, and then 
on directly to the process server via a data-type communications link. Event data 
20 generated within a service engine, be it internal or external, are communicated to the 
service engine communication layer 127, which then communicates the event to the 
process server. The data-type communications link between the service engines and 
the service engine communication layer can optionally be the same communications 
link used for interactive communication (as depicted in FIG. 2), or a different link. 

25 Once the application server receives the event data, it directs the 

processing of the event through various service engines, as appropriate. The 
application server selects the appropriate service engines based upon the source of the 
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data, the type of event that the data represents (e.g., a financial invoice, a status update 
on a shipment or a notification received from a particular country's customs service) 
and/or the content of the data (e.g., the exporting and importing countries, the 
nationalities and/or identities of the buyer and seller, the classification and type of 
5 goods, the value of the goods and the toxic or environmental relevance of the goods). 
In the subsequent processing of the event, additional events and queries can be 
generated. 

The information sources 129, which are typically governmental or private 
entities outside the firewall 123, are also linked in communication with the external 

10 message broker 111 via connections configured for communicating data objects 
(denoted as being for data transfer by a "D" in FIG. 2). In some cases, they can 
generate events such as update notifications, sending those events to the application 

: server via the external and internal message brokers. Additionally, service engines 
and/or reference servers can query the information sources for information. 

15 The application server 125 and service engine communication layer 127 

provide authentication and security for verification of each service engine's usage 
rights in the TLCL system with relation to a given event In particular, the application 
server, which governs the operation of the service engines, controls the selection of 
service engines that receive an event. The service engine communication layer then 

20 polices the events passed from one service engine to another in comport with the 
dictates of the application server. 

TLCL System Functionality 

A user of the TLCL system, such as a Customer 101, a Service Activity 
Provider 1 13, or the TLCL System Provider, can access the functionality of the TLCL 
25 System by contacting the web portal 105 via a web browser over the Internet 107, an 
intranet, or another network connection. The user's interactive communications to the 
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TLCL system are preferably configured for World Wide Web-based protocols, such 
as are used by systems operating in HTML (Hypertext Markup Language), XML 
(Extensible Markup Language), XSL (Extensible Stylesheet Language), Java, JSP 
(JavaServer Pages) and Epicentric. 

5 As described above, the user's communications are passed via the web 

browser 105 through the firewall 123, and are screened for various levels of access 
rights by the firewall 123, the web portal 105 and the application server 125. 

The application server 125, typically developed in an appropriate 
middleware such as bluestone products or Enterprise Java Beans, is preferably 

1 0 configured to seamlessly guide a user through the processes that are relevant to them. 
In particular, it is configured to guide a Customer 101 through import/export related 
processes, to guide a Service Activity Provider 113 through their relevant import/export 

Z related activities, and to guide any user through any authorized reporting, auditing, 
and/or accounting procedures. Preferably, after the user selects the activity that the 

1 5 user requires, the application server both guides the user into and through each relevant 
service engine, and buffers their interaction with each service engine to provide a 
consistent, user-friendly interface that characterized by a consistent look and feel, 
consistent terminology and easy-to-understand instructions, hi doing so, the 
application server preferably accesses information on the various TLCL requirements 

20 of different countries and different users, to selectively activate the service engines 
(and portions of service engines) most appropriate to the user's needs. 

The service engines and reference servers are configured to pass and store 
data such that each function is provided related data from other functions to simplify 
the user's experience. For example, upon the classification of goods, the application 
25 server might direct the user through a process that verified whether the goods raise 
legal issues regarding toxicity. 
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A user of the TLCL system, such as a Customer 101, a Service Activity 
Provider 113, or the TLCL System Provider, can also access the functionality of the 
TLCL System by passing data objects directly from an information system to the 
external message broker 1 1 1, or even to the internal message broker 161 if a separate 
5 hole is maintained in the firewall. The external and/or internal message brokers rout 
the data object to the application server 125, which then directs the appropriate service 
engines to process the event 

In their operations, the service engines might also take data and/or 
instruction from each other or from other software packages, typically receiving 

10 information in data-type objects. For example, when a customer first conducts a 
transaction, they may use local ordering processing software that generates financial- 
invoice-type data objects in their local information systems 109. These data objects 
can be transmitted via the external message broker 111 and/or internal message broker 
161 to the application server, which forwards the objects to appropriate service 

15 engines, where the data is used to initiate and instruct certain processes. One such 
process could be the generation of a customs invoice from the fmancial-invoice-type 
data, and the transmission of the customs invoice to an appropriate broker using 
whatever communications technology that the broker is known to use. The process 
could also include selecting a broker based on past performance criteria stored in the 

20 system. Other related processes would be one to monitor the broker's performance 
when the broker reports its status, and add that performance data to a database of past 
broker performance. 

The service engines will frequently include or rely upon extensive 
databases and lookup tables reflecting the current requirements based on the countries 
25 of shipping origin, shipping destination, and intermediary travel, as well as the 
countries of the Buyer's and/or Sellers citizenship. Included among these are various 
national and international rules and regulations, import and/or export licensing 
requirements, duty rates, classification codes, and other customs limitations, such as 
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for toxic substances, packing materials, restricted parties and countries, auditing 
requirements, and the like. 

The many governments of the world have a variety of such TLCL 
requirements in the form of import laws, regulations, rales, best practices and the like 
to deal with these subjects. These TLCL requirements change frequently. Whether it 
is a governmental agency or a private information service, the Information Source 
offers access to up-to-date information to computer systems, providing compilations 
of this information and/or frequently updated lists of TLCL requirement changes. 
These Information Sources can also be provided within components of the information 
systems operated by Customers, Application Service Providers and/or Service Activity 
Providers. 

For the service engines, the external message broker 111 could serve as 
a gateway for updating the database information on a periodic and/or selected basis. 
For the internal service engines 131 and 133, the internal message broker 161 is also 
part of that gateway. Thus, at periodic intervals, at the instruction of the TLCL System 
Provider, upon receiving an update notification from an information source, or possibly 
at the request of a user, the service engine and the information source interact to 
updates the data contained in the service engine. The internal and external service 
engines can alternatively be updated through other forms of communication. This is 
particularly true for service engines that are not owned, operated or directed by the 
TLCL System Provider. 

Service Engines 

The application management system is preferably configured to work 
with a plurality of internal service engines 131 and 133 and a plurality of external 
service engines 135 and 137. Each service engine is configured to provide one or more 
services relating to one or more TLCL issues that arise in international import and/or 


10011098-1 

32 

export business transactions. Most service engines are configured either to run 
autonomously or to interact with a limited set of other service engines and/or 
information servers to accomplish a limited task or set of tasks. 

Some service engines may be designed and written by (or under the 
direction of) the TLCL System Provider. Such service engines are generally operated 
within the firewall by employees or contractors of the TLCL System Provider. Other 
service engines might be applications written and owned by outside software 
developers, but that are significantly altered and/or configured to meet the functional 
needs and/or the connection requirements of the TLCL system. These service engines 
could readily be either inside or outside the firewall, most likely depending upon the 
party that operates the service engine. 

Finally, some service engines are likely to be applications that are 
entirely owned and operated by outside entities. These entities could be Application 
Service Providers having expertise in some segment of the import/export industry, or 
even Customers 101 or Service Activity Providers 1 13 who are selling their information 
and expertise for additional profit. Therefore, while the external service engines 135 
and 137 are depicted separately, it should be understood that they could reside in the 
information systems of the Customers or Service Activity Providers. 

It typically is highly beneficial to use the service engines of Service 
Engine Operators such as Application Service Providers, Service Activity Providers 
and/or Customers that have significant import/export experience. These Service Engine 
Operators can have significant expertise in their particular services and/or localities of 
operation. Additionally, these Service Engine Operators might have existing business 
relationships, computer connections and/or information sources that are highly 
beneficial to the Customers. Indeed, it is unlikely that a single company will produce 
the best-of-breed software either for every TLCL function or in every legal jurisdiction. 
Included among the external service engines that might be accessed are tax calculation 
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engines, logistics information and negotiations, goods classification engines, and 
repositories to track transactions. 

Because different engines might be preferable depending on the exporting 
country, the importing country, the nationality of the buyer, the nationality of the seller, 
5 and even other issues such as the nature of the goods, there might be numerous service 
engines having similar functionality within the TLCL system. For example, one 
service engine might be used for import regulations in Europe, while another is used 
for import regulations in the United States. Furthermore, since service engines might 
include an integration of several functions, each having varying levels of desirability, 
10 it is very possible that the system will use one function out of a particular integrated 
service engine, while not using another (or only using the other for specific jobs). 
Additionally, the TLCL system could include service engines intended for use if other 
service engines are overloaded or suddenly unavailable. This would provide 
redundancy and thereby increase reliability. 

15 In some cases, Service Engine Operators might have developed service 

engines tailored to their individual needs. For example, departments within large 
TLCL clients might have developed software service engines configured to deal with 
TLCL issues that relate to issues relatively specific to the client's products, to the 
Client's locality, or the Client's other software systems (such as accounting systems). 

20 Likewise, Service Activity Providers might have service engines that primarily meet 
their own processing needs based on their own internal procedures. For example, a 
freight carrier might have logistics software configured to estimate its own shipping 
costs and track shipments through various stages of transportation. Likewise, a 
customs broker might have customs software configured such that, given the financial 

25 invoices that are in transit with purchased goods, the brokers can print out customs 
invoices formatted it the manner in which that broker chooses to operate. 
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SERVICE ENGINE FUNCTIONS 

The service engines can be configured to do a wide variety of functions. 
Some of these functions are interactive, and some relate to the use, manipulation, 
processing, storage, archiving, and reporting of data. The preferred embodiment 
5 preferably includes service engines configured to form five integrated, primary- 
function engines: a tax engine, an export engine, an import engine, a logistics engine 
and a payment engine. The preferred embodiment also includes service engines 
configured to provide customer management and reporting. Other embodiments could 
include additional functional engines, such as ones to assist in making legal decisions 
10 or manage financial transactions for international trade. 

Tax Engine 

The tax functional engine comprises one or more service engines that 
provide information, assist in reporting and/or assist in paying various taxes relating 
to transactions in jurisdictions around the world. Related databases include a database 
15 of tax rates for each tax jurisdiction, as well as any product classification information 
necessary to assess the correct tax rates. 

Preferably, buyers and/or sellers can access the tax engine to determine 
the tax-cost of each potential transaction. This can be particularly important for large 
entities, which can ship orreceive goods in any of a number of different countries. The 
20 savings resulting from selecting optimal shipping sources and destinations can be quite 
substantial. Such a calculation will generally need to consider the variation in other 
costs such as shipping, customs, and related support (e.g., brokering). These other 
costs are preferably available through other engines, as described below. 

The tax functional engine also can serve as a repository for tax payment 
25 information. This provides both for the correct payments of transaction tax, and for the 
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efficient reporting of transaction tax payments to the financial entities that calculate 
and pay regular corporate taxes. 

Export Engine 

The export functional engine includes service engines each having 
5 functionality to take care of export issues in one or more jurisdictions. One typically 
important export issue is the tracking and reporting of export transactions to meet the 
governmental summary reporting requirements of most countries. Also included are 
warnings against export limitations that various countries might have. For example, 
exports from the United States, and shipments by US entities (regardless of the export 
1 0 locations), are subject to restrictions on parties and/or countries that can receive the 
goods. Likewise, certain technologies and substances are restricted. 

While many exports are not limited, licenses are required for exporting 
various goods from many countries. The export engine is preferably configured with 
service engines that verify a client has the proper export licences, and that act to apply 

15 for needed licenses. In any countries where such applications can be done 
electronically, the actions are preferably taken directly by tile service engines. In other 
countries, the service engine preferably communicates with appropriate staff (at the 
Client, the TLCL System Provider, or an outside vender of such services), directing 
them to apply for the appropriate license, fn either case, the service engine also acts 

20 or otherwise flags the export so that it is delayed until it is properly licensed. 

Related databases accessed by the service engines of the export 
functional engine preferably include a database of the export reporting requirements 
of each jurisdiction, a database of the laws regarding restricted parties and countries 
with which to do business, a database of the licensing requirements of each 
25 jurisdiction, a database of the licenses actually held by the clients, and any product 
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classification information necessary to assess the licenses needed for any given 
transaction. 

The export functional engine also can serve as a repository for export 
information used in the re-importation of components within larger products, i.e., the 
export of goods by a first party to a manufacturer that will take the goods and 
incorporate them into products to be sold back to the first party. This activity is 
referred to as an assist. Various import options exist for claiming an assist, and 
preferably the service engines of the import functional engine can access both the 
export engine (or its records) and the client's customs preferences to determine what 
types of assist claims will be made. 

Additionally, the export functional checks a repository for import 
information for indications that the exported goods were previously imported and that 
duties were previously paid. For such cases, the export engine activates service 
engines to arrange for drawbacks (i.e., a refund of the duties that were previously paid). 
In some countries this will entail a shipment-by-shipment application, while in others 
it will entail the entering of a database entry, along with a summary application being 
generated periodically. 

Import Engine 

The import functional engine includes service engines having 
functionality to take care of import issues in one or more jurisdictions. One typically 
important import issue is the handling of imported goods through customs, whether by 
the client themselves or a third party customs broker. Central to the import process is 
the proper description and classification of goods. Also, of high importance are the 
consistent description and classification of goods. These are both important for legal 
compliance with import laws in most jurisdictions. Additionally, duties need to be 
calculated, paid, tracked and reported for corporate financial considerations. Also, 
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various formats and preferred business practices should be adhered to, depending on 
the jurisdiction. 

To manage these issues effectively, the import functional engine 
preferably includes one or more service engines that generate, or assist in the 
generation of, customs invoices that consistently and accurately describe the products. 
Preferably these service engines take into account both the bast practices and the legal 
requirements of each country, as well as prior rulings by each country on each client's 
goods. The service engines also preferably account for any assists that are to be 
claimed during import, such as is described above with regard to the export functional 
engine. The service engines deliver the customs invoice information to the appropriate 
broker or company representative in the import jurisdiction in a timely fashion, 
preferably prior to the arrival of the goods to minimize the time spent in customs. 
Also, a service engine records the transaction such that the export engine can access 
the information and check for potential drawbacks. 

To the extent possible, a customer can use the import functional engine 
to query a broker status of the import operation, and to study the history of 
performance by various brokers when selecting a broker to use. Alternatively, the 
functional service engine can select a broker based on its cost and history of 
performance. 

Additionally, some countries include various limitations on the products 
and packaging that can be imported. These limitations can be trade limitations on 
products that have been imposed by certain governments. They can also be health, 
safety or environmental limitations, such as relating to dangerous substances, protected 
species, or pollution/recycling requirements on products and/or packaging. They can 
even be restricted parties or countries for trade, which was already discussed above 
with regard to the export engine. 
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The import engine is preferably configured with service engines that 
verify that the goods, the packaging, the trading partners and the exporting countries 
all are proper under the importing country's laws. In cases where significant issues 
arise that cannot be handled by the service engines, the system notifies specialists (at 
5 the Client, the TLCL System Provider, or an outside vender of such services) that 
action must be taken. 

Related databases accessed by the service engines of the import 
functional engine preferably include a database of the acceptable product descriptions 
and classifications for each jurisdiction, a database of the customs rules, best practices 

10 and procedures of each jurisdiction, a database of the import restrictions and health 
/safety/environmental requirements of each jurisdiction, and a database of the product 
types of each client, along with prior rulings governing their classification in various 
jurisdictions. Also, a repository of import information, including duties paid, time in 
customs, and parties managing the customs operation, is preferably maintained. This 

1 5 repository is used both for various financial considerations and for the analysis of the 
performance of customs brokers and/or related parties. 

Logistics Engine 

The logistics functional engine includes service engines having 
functionality to manage logistics issues through various jurisdictions. Related 

20 databases accessed by the service engines of the logistics functional engine preferably 
include a database of freight forwarders and carriers serving various types of cargo in 
various markets, along with their rates and any discounts that can be had due to 
connections with the Buyer, the Seller, the TLCL System Provider, or other related 
parties or factors. Also, included can be a database of historic information on various 

25 performance factors of the carriers. 
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Preferably, buyers and/or sellers can access the logistics engine to 
determine the cost efficient course of shipping, considering the available forwarders 
and/or carriers, considering the various discounts that have been arranged due to 
business arrangements with the forwarders and/or carriers, and considering the history 
of on-time and safe delivery of cargo by each forwarder and/or carrier. To the extent 
possible based on forwarder/carrier arrangements, a customer can use the logistics 
functional engine to arrange shipments, and to query the forwarder/carrier for location 
and status information on the shipments. 

The logistics functional engine also can serve as a repository for historic 
logistics information. This provides both for the analysis of carrier performance and 
the selection of preferred carriers. 

Payment Engine 

The payment functional engine includes service engines having 
functionality to manage payments (i.e., to instruct payment entities regarding payments, 
or to initiate electronic payments) made to outside vendors and/or governmental 
agencies for the various fees and services incurred in the TLCL portion of a business 
transaction that results in the international shipment of goods. Included among these 
payments can be customs brokers' fees, freight forwarders' fees, carriers' fees, other 
Service Activity Providers' fees (including any fees due to the TLCL System Provider), 
fees to related providers of information or electronic services, and duties. Related 
databases accessed by the service engines of the payment functional engine include any 
needed to identify costs related to the above types of payment. Also included can be 
a database of historic information on various payments actually made for various 
accounting purposes. 
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Additional details on some service engines of the present invention are 
contained in the following applications, which were incorporated by reference into the 
parent application of the present application. 
5 1) PCT patent application, entitled "Methods of Creating Electronic Customs 

Invoices", Serial No. , filed in the US Receiving Office on October 1, 

2001, under the attorney docket number 10012294-1, which is hereby incorporated 
herein by reference for all purposes. 

2) PCT patent application, entitled "Order Fulfillment Architecture Having An 
1 0 Electronic Customs Invoice System", Serial No. , filed in the US Receiving 

Office on October 1, 2001, under the attorney docket number 10012299-1, which is 
hereby incorporated herein by reference for all purposes. 

3) PCT patent application, entitled "Regulatory Classification System", Serial No. 
, filed in the US Receiving Office on October 1, 2001, under the attorney 

1 5 docket number 10002302-1, which is hereby incorporated herein by reference for all 
purposes. 

4) PCT patent application, entitled "Export License Determination Server", Serial No. 

, filed in the US Receiving Office on October 1, 2001, under the attorney 

docket number 10002306-1, which is hereby incorporated herein by reference for all 

20 purposes. 

5) PCT patent application, entitled "Transaction Monitoring System", Serial No. 

, filed in the US Receiving Office on October 1, 2001, under the attorney 

docket number 10002307-1, which is hereby incorporated herein by reference for all 
purposes. 

25 These five applications add further detail and scope to preferred 

embodiments the present invention, and are considered an integral part thereof. They 
also provide examples of the interaction of service engines under the present invention. 
For example, the service engine that generates a customs invoice, such as from 
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financial invoice information, makes extensive use of the Regulatory Classification 
System. Additionally, the transaction being handled by these two service engines 
would need to have export license approval, and thus the Export License Determination 
Server would likely operate on related messages for the transaction as well. The 
5 operation and communication of these service engines, and the other service engines 
with which they interact, define patentable systems and methods, and are within the 
anticipated scope of the invention. 

MESSAGE BROKERS 

The internal and external message brokers, 161 and 111, respectively, 
10 work in conjunction as a gate-keeping message broker to facilitate data 
communications between the application server 125, service engines (both internal and 
external), reference servers 139, information sources 129, Service Activity Provider 
information systems 117, and other Customer information systems 109. When 
managing the data objects, the message brokers preferably provide a number of relevant 
15 functions. 

First, each message broker preferably includes a variety of different 
interconnect technologies, at least one of which is configured to interconnect and 
receive data communications from each service engine, internal reference server, 
information source and/or information system to which that message broker will 
20 connect. The data can be in a wide variety of formats, such as a flat file record, an 
electronic data interchange ("EDI") of structured data according to agreed message 
standards between computer systems, a spreadsheet entry, extensible markup language 
("XML") or web data. The message brokers will preferably have a standard 
communication format that is efficient for processing large amounts of data. 

25 One or more message brokers also preferably include routers 

programmed with routing logic. The routing logic will preferably be based on the 
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substantive data type (e.g., financial invoice data or updated governmental 
requirements) and the source of the data received. This allows for updating the data 
routing via changes to tables in the message brokers without reprogramming various 
service engines, information sources, and the like. Data objects received by the 
5 message brokers from some or all sources could include supplemental routing 
information, either to supplement internal routing logic, or to override it. Alternatively, 
the message brokers could be configured for all routing information to be included with 
each type of data object. 

In addition, one or more message brokers are preferably programmed to 
10 include data editing and verification checking modules, extending them beyond the 
traditional roles of a message broker. Such modules would preferably include data 
format and/or substantive data checking information for various types of data. These 
modules would preferably use substantive logic based on the data type, and would 
verify the logical correspondence of data within a data object. Upon finding 
1 5 questionable or faulty data, the quality checking modules could reject the data back to 
its source, correct the data and/or direct the data to experts that can research and correct 
the issues in the data. 

Because the message brokers are configured to work with a wide variety 
of data formats, the message brokers are preferably configured with data translation 
20 modules. These modules would provide the needed translation to place the data into 
each format required by each destination for the data. Given that data can be directed 
to a variety of destinations, it is possible that it will have to be translated into a variety 
of formats. 

As an additional note, while the external and internal message brokers 
25 are depicted as a single entity, other configurations are within the scope of the 
invention. For example, two or more external message brokers could be interlinked, 
each having additional links to a different set of service engines, information sources, 
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reference servers and/or information systems. Thus, competing providers of external 
message broker services could join forces to avoid creating redundant connections. 
Likewise, multiple internal message brokers could be used to connect multiple sites (or 
multiple levels of firewall security) associated with the TLCL System Provider. 

Additional details on the message brokers and their advanced functions 
are contained in a US patent application entitled "Combined Message Broker", Serial 

No. , filed concurrently with the parent application to the present 

application on October 1, 2001, under the attorney docket number 10012320-1, which 
is hereby incorporated herein by reference for all purposes. Further details on the 
message brokers and their advanced functions are contained in a US patent application 

entitled "Verified Message Broker", Serial No. , filed concurrently with 

the parent application to the present application on October 1, 2001, under the attorney 
docket number 100123 19-1, which is hereby incorporated herein by reference for all 
purposes. 

These two applications add further detail and scope to preferred 
embodiments the present invention, and are considered an integral part thereof. They 
also provide examples of the mechanism of interaction of the service engines and other 
related modules, under the present invention. The operation and communication of 
these message brokers (with related disclosed modules), with the TLCL system, 
including the service engines that are incorporate by reference above, define patentable 
systems and methods, and are within the anticipated scope of the invention. 

OTHER FEATURES OF THE INVENTION 

In the disclosed embodiment, an application management system, a 
message broker and a set of service modules are described as being within a single, 
global firewall. However it should be understood that the architecture of corporate 
networks can take many forms, with multiple layers of firewall or numerous local 
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firewalls instead of a single, global firewall. The present system can be implemented 
in different forms, such as being distributed across various forms of network 
architecture. For example, for the purposes of this description, two network systems 
that are each protected from a public network by a firewall, and that are in 
communication through secure communications channels, are simply one network 
behind a firewall, as is discussed above. 

While customers are described above as buyers or sellers, there are other 
entities that might act as customers. For example, Service Activity Providers or even 
Application Service Providers could become customers to provide their respective 
customers with the benefits of the available TLCL solutions. Indeed, such customers 
might find the TLCL solution to be superior to their in-house software for some 
purposes, and incorporate the system into their regular procedures. 

It is to be understood that the invention comprises apparatus, software 
and methods for designing setting up, managing and operating service engines, and 
particularly for designing setting up, managing and operating TLCL service engines 
and their supporting architecture. Additionally, the invention comprises apparatus, 
software and methods related to using the services of TLCL service engines and their 
supporting architecture. In short, the above disclosed features can be combined in a 
wide variety of configurations and relate to a wide variety of licensees within the 
anticipated scope of the invention. 

While particular forms of the invention have been illustrated and 
described, it will be apparent that various modifications can be made without departing 
from the spirit and scope of the invention. Thus, although the invention has been 
described in detail with reference only to the preferred embodiments, those having 
ordinary skill in the art will appreciate that various modifications can be made without 
departing from the scope of the invention. Accordingly, the invention is not intended 
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to be limited by the above discussion, and is defined with reference to the following 
claims. 


